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1) Introducción a los videojuegos bajo SDL: 


La industria del videojuego ha ido creciendo últimamente, superando incluso a la del cine, 
eso es o un muy buen síntoma para la industria del videojuego, o un muy mal síntoma 
para la del cine. El caso es que desde el punto de vista de la programación, afrontar la 
creación de un videojuego es un interesante reto. No importa cuantos juegos hayas 
creado, siempre habrá algo nuevo que hacer, o que no hayas hecho antes, al contrario 
que otras areas donde sabemos que siempre va a ser sota, caballo y rey (o altas, bajas y 
modificaciones, aplicado a la informática). 


Y todo parece ir bien en la industria del videojuego, si no fuera por un tema 
aparentemente "sin importancia". El tema en cuestión es, que si bien la plataforma del 
sistema operativo predominante windows, está infestado hasta la saciedad de 
videojuegos, no pasa lo mismo con linux, la alternativa más interesante ante lo habitual 
del windows. La razón sin duda se encuentra en el no muy sorprendente hecho, de que la 
gran mayoría de los juegos comerciales, son realizados con la API DirectX de Microsoft. 
Al no ser una API de código abierto, es complicado encontrar bajo Linux una API que 
trabaje aparentemente de la misma forma. 


Pero por suerte, gente con tiempo libre y ganas de ayudar al mundo, crea API 
multiplataforma como SDL. Por ello gracias a librerías como la SDL, no tendremos que 
reescribir partes del código, a la hora de portar un juego de windows a linux y al revés. 
Básicamente es como matar un pájaro de dos tiros, y tener no solo esa inmensa mayoría 
de usuarios de windows, sino que además también mediante APIs como esta, los 
usuarios de sistemas operativos alternativos (no solo linux, también mac está soportado 
por SDL), podrán tener el mismo juego con un esfuerzo mínimo, y esto equivale a más 
posibles ventas. Así que la industria saldría beneficiada, y los que no usan windows 
también. Porque aquel que se compra un Mac, no creo que le sobre mucho dinero para 
un PC... XD 


Para aquellos que hacen juegos de forma amateur, también sería importante su 
colaboración, para que plataformas como linux dispongan de sus juegos, para así ir 
quitando poco a poco una de las últimas barreras que todavía tiene linux (aunque hay 
quien asegura que es un "mito", si es que el buscaminas da para miles de horas de juego, 
sí), MacOS, y en general todo aquello que no sea el camino único dictado por windows. 


2) Creando proyectos para la SDL: 


Bien dejando los rollos introductivos, que todo el mundo se salta, pasemos a lo siguiente. 
Si estás haciendo tu proyecto bajo windows, en la documentación de las SDL viene unas 
indicaciones importantes sobre como configurar tu proyecto bajo Visual C++ 6.0. Tienes 
dos opciones a la hora de crear un proyecto, que sea una aplicación Win32 de Consola, o 
una aplicación Win32 de Ventana. Si eliges que sea de consola, te saldrá por detrás la 
bonita consola de MS-DOS tan querida por algunos. Eso puede quedar ciertamente feo, 
por ello es recomendable elegir "Win32 Application". Una vez creado nuestro proyecto, 
que deberá estar vacío, para evitar que el VC te meta mierda típica de wndows, hemos 
de ir a las propiedades del proyecto (pulsando ALT+F7, o su alternativa "Project -> 
Settings...”). Una vez nos salga el cuadro de dialogo de las propiedades del proyecto, 
hemos de seleccionar la pestaña "C/C++", allí hemos de elegir la opción "Code 
Generation" de la propiedad "Category". Entonces es cuando hemos de cambiar tanto 
para el "Win32 Debug", como para el "Win32 Release" de nuestro proyecto, la opción 
"Use run-time library", y escoger siempre Multithreaded DLL. Y en la pestaña "Link", en la 
casilla de "Object/library modules:" hay que agregar SDL.lib y SDLmain.lib. Aunque otra 
forma de hacerlo es escribiendo lo siguiente en nuestro programa: 


// Con este ifdef cuando lo compilemos con el gcc, se saltará este fragmento 
// de código. Además la directiva pragma comment (lib, "fichero.lib") nos sirve 
// para añadir nuevos ficheros.lib, sin tener que meternos en las propiedades 
// del proyecto actual. 






































ifdef WIN32 

pragma comment (lib, "SDL.lib") 

pragma comment (lib, "SDImain.lib") 
ndif 








Así que en resumidas cuentas hay que hacer algo tal que: 





"Project -> Settings... -> C/C++ -> Category = Code Generation -> 
Use run-time library = Multithreaded DLL" 


Sin embargo para linux, ese SO tan "difícil", el único parámetro especial que hay que 
poner al compilador gcc es el siguiente fragmento de texto: "sdl-config --cflags --libs*. Para 
que luego digan que linux es imposible de manejar. El caso es que nos quedaría una 
llamada al gcc tal que: 


gcc 'sdl-config --cflags --libs' -o prueba prueba.c 


Obviamente es preferible que os hagais un makefile, para poder gestionaros proyectos 
con varios ficheros fuente, o un guión shell si lo prefiere alguien. Eso es tan solo una 
cuestión de gustos. 


3) Iniciando el juego con SDL: 


Para evitarnos problemas con cualquier compilador de C, la función principal es preferible 
que sea un: 


int main (int argc, char ** argv) 
[ 

rasa 
) 


Una vez llegados a este punto hemos de tener en cuenta el esquema universal de las 
cosas, por lo tanto el esquema universal de un programa cualquiera. Todo juego al 
menos, tiene una inicialización, para luego pasara a la ejecución del juego mismamente, y 
terminar con una finalización del mismo. Pero antes que todo esto, hay que tener en 
cuenta una cuestion muy importante. Esta cuestión es el tema de los datos del juego. 
Muchas veces, en aplicaciones sencillas se tiende a hacer las variables globales, ya que 
para evitarnos engorros de punteros por aquí y por allá, y funciones con 24 mil 
parámetros, se suele tender a soluciones como esa. Pero eso es totalmente inviable en 
proyectos con muchos ficheros fuente, por eso nos deberíamos crear un tipo estructurado 
para almacenar las variables "globales" de todo el juego: 


typedef struct 
[ 


// Variables de las que depende el funcionamiento del juego. 
) tNucleo; 


En C++ crearíamos una clase (class CNucleo), donde almacenar todos los datos, y esta 
clase solo tendría variables básicamente. El por qué evitar poner rutinas que manejen 
esos datos, es por el mero hecho de que al final, acabaríamos "teniendo" que meter todas 
las funciones en la misma clase, y eso no es muy elegante, no. Así que una vez tengamos 
nuestro nucleo de datos, el main quedaría algo como: 


int main (int argc, char ** argv) 
( 


tENucleo Nucleo; 





InitJuego(éNucleo, TRUI 
BuclePrincipal (Nucleo 
FinJuego ($Nucleo); 


800, 600, 32); 





— H 
so o 











return 0; 


Hay quien hubiera declarado Nucleo como un puntero directamente y hubiera hecho un 
malloc, pero francamente eso sería buscarse complicaciones del todo innecesarias. En 
InitJuego() el programa se encargaría de inicializar el juego, que no inicializar la partida, 
dado que partida y juego son dos cosas distintas. Básicamente el esquema que seguiría 
la función sería: 


void InitJuego (tNucleo * Nucleo, // Variables del programa. 


int winmode, // Indica si queremos que esté en modo 
ventana. 

int width, // Ancho de la ventana. 

int height, // Alto de la ventana. 

int bpp) // Número de bits de profundida del color. 


// Inicializamos la SDL creando el buffer primario de la pantalla. 


// Activamos la entrada por teclado y ratón bajo SDL. 
// Cargamos las imagenes del juego. 


// Cargamos las imagenes con las fuentes. 





// Cargamos las puntuaciones. 





// Y terminamos de inicializar el resto de datos importantes para el juego. 





4) Iniciando la SDL y el modo de video: 


Como pasa con otras tantas librerías y APIs, la SDL antes de usarla, debemos 
inicializarla. En este caso particular la cabecera de la función sería algo como: 





SDL Surface * CrearBufferPantalla (int winmode, char * title, 
int width, int height, int bpp) 





Llegados a ese punto lo primero que hay que hacer es llamar a la función SDL_Init, a la 
que le hemos de pasar los sistemas del SDL que queremos activar. Normalmente 
activaremos el sistema de video (SDL_INIT_VIDEO), el sistema de audio 
(SDL_INIT_AUDIO) y el sistema de gestión del tiempo (SDL_INIT_TIMER). En la ayuda 
vienen un listado con todos los sistemas disponibles, todos los que queramos activar los 
tendremos que encadenar con el operador | (or a nivel de bits). SDL_Init siguiendo las 
buenas costumbres del clásico Unix, devolverá -1 en caso de fallar. La llamada podría 
quedar tal que: 


if(SDL Init(SDL _INIT VIDEO|SDL_INIT_AUDIO|SDL_INIT_TIMER) == FAIL) 
Salir("No se puede iniciar la librería SDL.An", -1); 




















Con este fragmento de código inicializamos el SDL, y comprobamos si da fallo (tdefine 
FAIL -1). En caso de darlo, llamamos a la función Salir, pasandole una cadena con un 
mensaje de error y el código de salida de la aplicación. El código de esta función puede 
ser algo como: 


void Salir (const char * mensaje, int error) 

[ 
// Mandamos el mensaje d rror por pantalla. 
printf ("Ss", mensaje); 
printf ("Ssin", SDL GetError()); 








// Hacemos que el ratón esté mostrado y desactivamos la SDL. 
SDL ShowCursor (SDL ENABLE); 
SDL Quit (); 























// Salimos devolviendo el código de error. 
exit (error); 


Después de lograr activar la SDL, lo siguiente que tenemos que conseguir es crear el 
buffer principal de la pantalla. Pero si bien es cierto que conocemos el ancho, el alto y la 
profundidad que va a tomar el buffer principal, para crearlo bajo SDL nos falta saber 
algunas características más que podría tener. Estas características se las podemos pasar 
en una variable flags: 


if (winmode) 
































flags = (SDL_HWSURFACE |SD , DOUB EBUE); 
else 
flags = (SDL HWSURFACE|SDL DOUBLEBUF|SDL FULLSCREEN) ; 











Alguna de esas características que puede tener un buffer en SDL son: 

+ SDL_HWSURFACE = Que básicamente es una directiva de preferencia, con la que le 
indicamos que todas las imagenes que cargemos en un buffer (que SDL las llama 
surface, y las llamaré texturas), sea buffers que estén ubicados preferiblemente en la 
memoria de video de la tarjeta, en vez de la memoria ram normal. Esto será más rápido 


para la aplicación. Obviamente si no hay espacio en la memoria de video, los carga en 
la memoria ram normal. 

+ SDL_DOUBLEBUF = Esta característica hace que tengamos dos buffers de pantalla, 
uno estará a disposición de la tarjeta de video, para pintar su contenido en la pantalla, y 
en el otro será donde pintaremos la escena actual. Entonces para actualizar la pantalla 
con el nuevo contenido, llamaremos a SDL_Flip para que la tarjeta tome el buffer actual 
que acabamos de pintar, y nosotros nos pongamos a pintar sobre el que acaba de dejar 
libre. 

+ SDL_FULLSCREEN = Esta característica indica a la SDL que nuestra aplicación ha de 
ser ejecutada a pantalla completa. Si no la indicamos, la aplicación será ejecutada en 
modo ventana. 


Lo siguiente que hemos de realizar, es comprobar si el modo de video que queremos 
activar está soportado. Para ello usaremos SDL_VideoMode0OK, pasandole el ancho, el 
alto, la profundidad de color y los flags. Esta devolverá la profundidad de color máxima 
que soporta para dicho modo de video. Si devuelve cero, es que no lo soporta en 
absoluto. 


if(!'SDL VideoMode0K (width, height, bpp, flags)) 
Salir("Modo de video no soportado.An", -2); 


Finalmente podremos activar el modo de video que tanto deseamos. Para hacerlo 
usaremos SDL_SetVideoMode, pasandole lo mismo que le hemos pasado a 
SDL_VideoMode0K. SDL_SetVideoMode nos devuelve un puntero a una estructura de 
tipo SDL_Surface, que en caso de existir algún problema, nos devolverá NULL para 
indicar que existe un error. 


BufferPantalla = SDL SetVideoMode (width, height, bpp, flags); 





if (BufferPantalla == NULL) 
Salir("No se pudo activar el modo de video.An", -3); 





Como nota curiosa, si vamos a ejecutar nuestra aplicación en modo ventana, podemos 
cambiarle el título a esta, con la función SDL_WM_SetCaption, de la siguiente forma: 


SDL WM SetCaption("Mi peacho de juegorl1!!!", NULL); 


Finalmente devolveremos el puntero que nos devolvió SDL_SetVideoMode, 
almacenandolo en alguna variable, dentro de la variable Nucleo de la que hablamos al 
principio. Algo como: SDL_Surface * BufferPantalla; 


5) Iniciando la entrada por teclado y ratón: 


Otro tema generalmente importante en cualquier juego es la gestión de la entrada del 
usuario. Para esto normalmente la mayoría de los juegos de pc usan el teclado y el ratón. 
También se podría usar un joystick, pero es más comodo programar el tema del teclado y 
el ratón *_4 Como en todo el teclado y el ratón tiene una serie de datos que tenemos que 
almacenar en variables. Para el caso del teclado nos bastará con un vector de bytes. Esta 
variable para evitarnos problemas la meteremos en la estructura tNucleo, declarandola: 


VUint8 * Teclado; 


Nada muyy difícil no, sin embargo el ratón tiene muchas más propiedades, por lo que no 
estaría mal crearnos una estructura que englobara todos esos datos, tales como las 
coordenadas actuales del cursor del ratón, las coordenadas relativas (que son usadas 
para indicar cuanto ha incrementado o decrementado el valor de las coordenadas, se usa 
en juegos 3D de primera o tercera persona, por ejemplo), o el estado de los botones del 
ratón, para comprobar si están pulsados o no. Así que la declaración del nuevo tipo 
quedaría tal que: 


typedef struct 

1 

x;  //Coordenada absoluta X 

y;  //Coordenada absoluta Y 

rx; //Coordenada relativa X 

ry; //Coordenada relativa Y 

lb; //Estado del boton izquierdo 

cb; //Estado del boton central 

rb; //Estado del boton derecho 
int wu; //Indica si la rueda del raton se ha movido hacia arriba 
int wd; //Indica si la rueda del raton se ha movido hacia abajo 

) tMouseState; 


in 
in 
in 
in 
in 
Ea 
in 








A e O e O A e A a a a O sl 


Así que luego lo declaramos dentro de tNucleo como "tMouseState Raton;". Y entonces 
nos podemos crear nuestra rutina para inicializar la entrada por teclado y ratón. Para ello 
lo primero que haremos dentro de la función será llamar a la función SDL_PumpEvents, 
que actualiza el estado de la entrada en SDL. Solo que la primera vez que lo llamemos 
servirá para arrancar el sistema de entrada. Luego tendremos que inicializar el teclado, 
para ello llamaremos a SDL_GetKeyState, que nos devuelve un puntero del tipo Uint8. 
Esta dirección devuelta es donde SDL guarda el vector donde se almacena el valor de 
cada tecla. Así que cuando actualizamos la entrada, SDL comprueba el estado de todas 
las teclas, almacenandolo en ese vector, para que luego nosotros al tener la dirección, 
podamos comprobar luego la tecla que deseemos. Y finalmente inicializamos la estructura 
del ratón. Todo esto junto quedaría de la siguiente forma: 





void ActivarEntrada (tNucleo * Nucleo) 
( 
// Activamos el sistema de entrada del SDL. 
SDL PumpEvents (); 
Nucleo->Teclado = 





SDL GetKeyState (NULL) ; 


// Inicializamos la estructura del ratón. 
Nucleo->Raton.x 
Nucleo->Raton.y 
Nucleo->Raton.rx 
Nucleo->Raton.ry = 
Nucleo->Raton.lb j 
Nucleo->Raton.cb = FALSE; 


, 


, 


oooo 


Il 
= 
y se. 
Y 

] 


se 




















Nucleo->Raton.rb = FALSE; 
Nucleo->Raton.wu = FALSE; 
Nucleo->Raton.wd = FALSE; 




















Hay una función especial que sirve para ocultar el cursor que SDL pone para el ratón. Es 
la función SDL_ShowCursor que aparece en la función Salir. Solo tiene un argumento que 
puede valer SDL_DISABLE, para ocultar el cursor del ratón, o SDL_ENABLE para hacerlo 
visible. 
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6) Como cargar texturas almacenadas en una imagen: 


Los juegos normalmente están compuestos por imagenes, que guardamos en ficheros 
como los tga, jpg o bmp. SDL por si sola solo soporta la carga de BMP, pero existe una 
extensión para la SDL, que se llama SDL_image, que sirve para cargar otros tipos de 
ficheros que no sean un BMP. Aunque lo que sí es cierto que SDL permite crear una 
surface nueva con las dimensiones que queramos, y luego modificar los pixeles de dicha 
surface, con lo que podríamos implementar una rutina que lea tgas por ejemplo, y los 
carge sobre una surface. De todas formas para esos casos, es más recomendable usar 
SDL_image. 


Para cargar una imagen, primero tendremos que tener una variable surface donde 
cargarla, por ejemplo: "SDL_ Surface * imgFondo;". Y luego tan solo tendremos que llamar 
a SDL_LoadBMP. Esta función recibe como argumento la ruta del fichero bmp que 
queremos cargar, y nos devuelve un puntero a una surface creada por SDL. En caso de 
error devolverá NULL. El código de ejemplo quedaría del siguiente modo: 





Nucleo->Texturas.imgFondo = SDL _LoadBMP ("gf£x/fondo.bmp"); 
if (Nucleo->Texturas.imgFondo == NULL) 
Salir("No se pudo cargar la imagen fondo.bmp.An", -4); 


Cargamos el bmp en una surface, y luego comprobamos si realmente se ha creado dicha 
surface. En caso de que no haya sido así, lanzamos un error. Y en este caso, dada la 
importancia de la textura a cargar, salimos de la ejecución del juego lanzando un error. 
Pero en los juegos normalmente hay texturas que pintaremos encima de otras, como las 
naves, y dada la naturaleza de cualquier mapa de bits, estos son cuadrados. Así que esto 
sería un problema serio, pero es un problema que se resuelve usando un "color clave" 
para nuestra imagen. En el ejemplo uso el color rosa cantoso (define CCROSA 
Ox0OFFOOFF). Para asignar un color clave a una surface, hemos de usar la función 
SDL_SetColorKey, a la que le pasamos la surface que queremos modificar, la constante 
SDL_SRCCOLORKEY cuya función es indicar que estamos asignando el color clave de 
esa imagen, y finalmente el color que deseamos que actue como color clave. En caso de 
dar error, devuelve -1. 


1f(SDL SetColorKey (Nucleo->Texturas.imgMalosos, SDL SRCCOLORKEY, CCROSA) == 
FATL) 
Salir("No se pudo poner el color clave para malosos.bmp.An", -4); 





Luego cuando termine la ejecución de nuestro programa, o cuando no necesitemos 
alguna textura en particular, SDL nos ofrece la función SDL_FreeSurface, a la que le 
pasamos como argumento la surface que deseamos liberar de memoria. En este juego al 
ser tan sencillo, todas las texturas se cargan al principio, y se liberan al final. Pero en otro 
tipo de juegos cada vez que cargamos un nivel, seguramente cargaremos algunas 
texturas que necesitemos, y cuando lo finalicemos, liberaremos las que no necesitemos. 


SDL FreeSurface (Nucleo->Texturas.imgFondo); 


Otro tema importante sobre el tema de las texturas, viene asociado a la estructura 
SDL_Rect de SDL. SDL_Rect tiene solo 4 campos: x, y, w, h (w = ancho y h = altura). 
¿Para qué sirve? ¿Qué proposito tiene en la vida? Bien, muchas veces, sobre todo 
cuando tenemos animaciones, o tenemos la textura de todas las naves en una misma 
surface, la imagen tiene que ser manejada con regiones. Y eso es lo que representa 
SDL_Rect, regiones de una surface. En el juego tenemos el siguiente ejemplo: 


qa 


//Malo verde 


Nucl 
Nuc 
Nuc 
Nuc 


Nucl 
Nuc 
Nuc 


leo->1 
leo->1 
leo->1 


leo->1 
leo->1 


leo->1 


leo->1 








Nuc 


En una de las variables internas de Nucleo, tenemos el vector Malosos, que está 


leo->1 


a 


ex 
ex 
ex 
ex 


a 


a 


= 


//Malo azul 


SS 


ex 
ex 
ex 


á 


=j 





+ 


ex 





cturfaS. 
ctufaS. 
cturfasS. 
cturfaS. 


ctufaS. 
cturfasS. 
cturfaS. 
ctufaS. 








DOS p 


DO p 





losos 
losos 
losos 
losos 


losos 
losos 
losos 
losos 





oooo 


Rhbhrerr 


ZE DK »X 


E DK »X 





= 64; 


= 64; 
64; 





declarado de la siguiente forma: "SDL_Rect Malosos[MAXMAL];". En este caso particular 


son solo dos naves las que hay en la misma imagen, que contiene las naves enemigas. 
Por lo que nos creamos dicho vector para almacenar las regiones que existen dentro de 
dicha imagen. Esto así puede parecer que no tiene mucho sentido, pero luego cobrará 
sentido más adelante. 
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7) Como manejar el teclado y el ratón: 


Ahora explicaremos algo bastante fundamental, como es la interacción de la que 
dispondremos con el teclado y el ratón. Normalmente uno actualiza la entrada toda de 
golpe, es una de esas "buenas costumbres". Para ello es primordial primero llamar a 
SDL_PumpEvents, para que SDL actualice el estado total del sistema de la entrada. Con 
esto ya podremos saber el estado de cualquier tecla sin tener que llamar a ninguna 
función más, pero normalmente las aplicaciones suelen usar también el ratón (aunque sea 
solo para el menú). 


Por ello tenemos dos funciones para obtener datos referidos al ratón. Son 
SDL_GetMouseState y SDL_GetRelativeMouseState. La primera le tenemos que pasar 
por referencia un par de enteros donde almacenar las coordenadas x e y del ratón. 
Además nos devolverá un entero del tamaño de un byte, con el estado actual de los 
botones del ratón. La segunda pasandole también por referencia un par de enteros, 
almacenaremos las coordenadas relativas de la x y la y. 


Todo esto está muy bien, pero claro, también nos apetece saber el estado de los botones, 
ya sabes, para hacer click o disparar estilo Quake. Para ello tenemos que hacer una cosa 
la mar de linda, una de esas lindezas por las que el C es un lenguaje tan querido por 
muchos, pero simplemente lo apuntas, lo entiendes y lo usas para todas las veces que 
necesites codificarlo. La siguiente expresión: "(Botones 8 
SDL_BUTTON(SDL_BUTTON_LEFT)) == 1", siendo Botones esa variable Uint8, donde 
hemos guardado el valor devuelto por SDL_GetMouseState, nos indica para este caso en 
concreto si el botón izquierdo está pulsado o no. Obviamente devuelve cierto, en caso de 
que esté pulsado. Finalmente todo esto junto quedaría tal que: 





void ActualizarEntrada (tNucleo * Nucleo) 


( 





Uint8 Botones; 


// Actualiza la entrada bajo SDL. 
SDL PumpEvents (); 








// Actualiza el estado del ratón. 
Botones = SDL GetMouseState (€ (Nucleo->Raton.x), $ (Nucleo->Raton.y)); 
SDL GetRelativeMouseState (6 (Nucleo->Raton.rx), £€(Nucleo->Raton.ry)); 
































//SDL BUTTON(X) -> (SDL PRESSED<<(X-1)) 
Nucleo->Raton.lb = Botones SDL BUTTON == ; //SDL BUTTON LEFT 
Nucleo->Raton.cb = SDL BUTTON == ; //SDL BUTTON MIDDLE 











Nucleo->Raton.rb 
Nucleo->Raton.wu 
Nucleo->Raton.wd = 








SDL BUTTON 
SDL BUTTON 





Botones 
Botones 











; //SDL BUTTON WHEELUP 
; //SDL BUTTON WHEELDOWN 
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); //SDL BUTTON RIGHT 3 
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Y así tenemos a nuestra disposición todos los datos de forma actualizada, una de esas 
maravillas de la ciencia. Solo queda comentar como comprobar si una tecla está pulsada 
o no. Esto es muy sencillo, solo hay que ir la variable puntero del teclado, y tratarlo como 
un vector normal para ver si la tecla número el que sea, vale 1 (fdefine TRUE 1)o 
vale O (fdefine FALSE 0). Para el juego este en cuestión codifiqué una función, quizás 
un tanto "superflua", pero que así ganaba claridad en el código: 





int EstadoTecla (tNucleo * Nucleo, int key) 
[ 


// Devuelve si una tecla está pulsada o no. 
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(Nucleo->Teclado[key] 





el 


14 


8) El bucle principal del juego: 


Bien, ahora viene un tema bastante interesante, y ciertamente crucial. ¿Como demonios 
es el bucle principal de un juego? Bueno hay por internet, en particular la página de Jare 
un programador de Pyro Studios, que en un artículo suyo ponía un ejemplo "típico" de 
como es un bucle de juego. Para este caso no lo usé, porque no me acuerdo como era, 
salvo que había que escribir mucho 4 _4U 


No, en este ejemplo de juego, el bucle es ligeramente mucho más sencillo, pero en 
esencia sigue el esquema básico de las cosas. Todo juego se divide en dos cosas 
básicamente, pintar la pantalla, y ejecutar un ciclo de la lógica. Y no hay más. De hecho el 
sonido suele estar relacionados a eventos, que tienen que ver con la lógica del juego, y 
por eso se suelen meter dentro de esa parte del código. Los gráficos supuestamente 
también están relacionados con la lógica del juego. Pero lo están de una forma distinta, en 
cierto modo. 


El sonido como he comentado, está encadenado a eventos normalmente, cuando 
iniciamos una fase, ponemos una banda sonora, cuando disparamos, ponemos el sonido 
del disparo. Sin embargo el algoritmo de renderizar la escena, lo que básicamente hace 
es coger todos los datos, interpretarlos y pintar la escena. No se hace que si tu activas un 
botón se pinte inmediatamente que la puerta se está abriendo. Lo que se hace es cambiar 
los datos del juego, y a medida que estos cambian, se van reflejando en el renderizado. 





void BuclePrincipal (tNucleo * Nucleo) 


[ 





Vint32 Intervalo 0; 
UVint32 TiempoAnt = 0; 


do ( 
//Tomamos el tiempo de inicio 
TiempoAnt = DarTicks(); 


//Pintamos la pantalla 
PintarPantalla (Nucleo); 





//Calculamos cuanto tiempo ha tardado 
Intervalo = DarTicks() - TiempoAnt; 





//Y ejecutamos la lógica en base al tiempo transcurrido 
EjecutarLogica (Nucleo, Intervalo); 

















)jwhile (Nucleo->Partida.EstadoDelJuego != ESTSAL); 





Y ahí está un bucle principal, del juego que sirve de ejemplo para este artículo. Pero como 
seguramente habéis observado, hay algo más que dos sentencias. Primero, el juego entra 
en un bucle, que se ejecutará hasta que el estado del juego, indique que hay que salir. 
Luego preguntamos cuantos milisegundos lleva ejecutandose el juego, y lo almacenamos 
en TiempoAnt. Después renderizamos la escena. El siguiente paso será calcular el tiempo 
en milisegundos que se ha tardado en renderizar la escena, para que finalmente 
ejecutemos un ciclo de la lógica, pasandole la cantidad de ese intervalo de tiempo 
ocupado por el renderizado. 


Ahora es cuando tú te preguntas, ¿para qué cojones ha hecho eso? Así de primeras 
parece una tontería y ganas de complicarse la vida. Pero la realidad es que pensemos 
que pasaría si tan solo ponemos las sentencias de PintarPantalla y EjecutarLogica. Bien, 
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pintaríamos la escena y ejecutaríamos la lógica, justo como queríamos. Pero las cosas 
son muy bonitas en la teoría, no en la práctica. En la práctica nos puede ocurrir dos 
supuestos. El primero es que la escena se renderiza muy rápidamente, y cada frame 
tarda una miserable cantidad de tiempo. Claro ahora es cuando piensas, genial más fps 
(frames per second, imagenes por segundo), más calidad para mi juego. Vale sí, está bien 
tener una tasa de fps alta, pero el efecto indeseado por este tema, es que tan rápido 
como se te renderice la escena, será de rápido a la hora de ejecutar un ciclo de la lógica. 
Y claro, a priori no sabes cuanto va a tardar en pintarse la escena, y puede haber bajones 
en los fps o subidas, con lo que tendrías un finstro de juegorl, que se movería como si 
fuera chiquito de la calzada a toda leche, y a trompicones. 


Claro, esto francamente es algo poco deseable, que según empiezas la partida te maten. 
Pero hay otro posible efecto. Que el renderizado tarde un huevo y parte del otro, como 
pasa con el DooM 3, en un ordenador estandar de cualquier mortal (aunque siempre hay 
quien cree que todo el mundo tiene una nVidia 6800 de esas tan chulas, obviamente eso 
es que le sobra el dinero, o que no tiene ningún escrúpulo a la hora de conseguir ese 
dinero a cualquier precio). El efecto inmediato de esto, es que nuestro juego no solo iría a 
pedales gráficamente, sino que la lógica también. Pero sin embargo, a pesar de ir a 
pedales el DooM 3, eso no impide que el bicho que estaba a tomar por culo (no mucho en 
el DooM 3 con lo "grandes" que son las pantallas), al siguiente frame esté a la mitad de 
camino, y al siguiente ya te haya sodomizado de mala manera. 


Ciertamente son efectos que desearíamos a cualquier costa evitar. Por eso hemos de 
calcular cuanto estamos tardando en renderizar la escena actual. Porque así sabremos si 
estamos yendo muy rápido o muy lento, y podremos controlar mejor la ejecución de la 
lógica. Si se renderiza muy muy rápido, podemos hacer que la lógica se ejecute menos 
veces. Y si va muy muy rápido, podemos ejecutar varias veces la lógica, para 
compensarlo. Ahora quizás te preguntes algo como, pero la lógica no puede tardar mucho 
en ejecutarse, como pasa con el renderizado. Es bastante difícil que tardemos más en 
ejecutar la lógica, que en renderizar una escena. Normalmente, suponiendo que nos vaya 
fluido gráficamente el juego, la lógica suele tardar 10 veces menos en ejecutarse, que los 
gráficos. Esto ocurre gracias a esos apasionantes micros que ejecuta miles de millones de 
instrucciones por segundo, con lo que ya tiene que ser mucho lo que calcules para que 
aquello vaya a pedales. 


Sin embargo los gráficos, la cantidad de información que tiene que manejar la tarjeta, 
puede llegar a ser aberrante, por muchos millones de polígonos que pueda pintar por 
segundo. Porque luego tiene que mapear las texturas, y añadir efectos chorras como 
puede ser el bump mapping, u otros efectos que tienen que ir pixel por pixel calculando 
movidas. Al final nos encontramos con que hemos tenido que ejecutar una aberrante 
cantidad de instrucciones, por parte del microprocesado de la tarjeta gráfica. 


En SDL la función que nos da el número de milisegundos que ha transcurrido desde el 
inicio de la aplicación es SDL_GetTicks, que para este caso está en la siguiente función: 


Uint32 DarTicks (void) 
( 
return SDL GetTicks(); 


) 

Y también hay otra función de control del tiempo que nos puede resultar útil, que es 
SDL_Delay, que lo que hace es suspender la ejecución del juego durante un determinado 
tiempo, normalmente medido en milisegundos. Esto puede sernos útil para situaciones del 
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tipo: estamos capturando pulsaciones del teclado, y para que de una pulsación no nos 
meta MIL caracteres, capturamos un caracter y lanzamos un delay, para que le de tiempo 


al usuario de despulsar la tecla actual y pulsar la siguiente. En el juego está metida en 
esta función: 


void Delay (Uint32 ms) 
[ 





SDL Delay (ms); 
) 
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9) La gestión del menú: 


Normalmente todos los juegos suelen tener un menú, donde hacer el mono un poquito. 
Seguramente hay miles de formas de implementar un menú, aunque para esta ocasión lo 
que yo pensé que sería más lógico y coherente, sería el implementar una máquina de 
estados. Una máquina de estados, para el que no lo sepa, es un conjunto de estados, que 
ejecutan un algoritmo cada uno de ellos, y que dependiendo de que se vuelvan ciertas 
determinadas condiciones, pasan de un estado a otro. 


En este caso por ejemplo, nosotros empezamos en el estado "Menú de Nueva Partida". 
Cuando estamos en este menú tanto en la función de renderizado, como en la de 
ejecución de la lógica, ejecutaremos solo el código específico para nuestro estado (a 
veces dos estados pueden compartir justo el mísmo código, como pasa para la lógica de 
la pantalla de Opciones y la de Puntuaciones, aunque usan distinto código para renderizar 
la escena por ejemplo). Sin embargo cuando se cumple alguna condición determinada, 
que normalmente nosotros programaremos ese número finíto de condiciones de cambio, 
como puede ser por ejemplo hacer click sobre el botón de Opciones, entonces 
cambiaremos el estado de la máquina a un nuevo estado, en esta ocasión al estado 
"Pantalla de Opciones". 


Las máquinas de estados se suelen usar sobre todo en inteligencia artificial, para dar un 
determinado comportamiento finito, a una entidad específica. Pero en este caso, lo he 
usado para realizar el menú. ¿Por qué? La codificación clásica para hacer un menú, suele 
ser pintarlo, elegir una opción y ejecutar una opción según esa opción. Bueno, no da 
ningún problema eso, hasta que queremos volver a llamar al "Menú de Continuar la 
partida". Se podría hacer por el metodo "clásico", sin que supusiera muchos problemas, 
pero por ejemplo en el juego, tras morir pasamos a la pantalla para meter el nombre, y 
luego a la de puntuaciones. En la máquina de estados solo es indicar que al finalizar el 
juego, pasemos al estado de "Meter el Nombre", pero en la concepción clásica terminaría 
el juego y tendríamos que posiblemente montar un pollo del copón para poder llamar a la 
función para gestionar el tema de dichas secciones del menú, sin que lo haga cuando 
llamamos al menú desde el juego. Pero bueno, en esto ya entra dentro de las 
preferencias de cada uno. 


Y el caso es que, con la máquina de estados por ejemplo, podemos separar los 
algoritmos de renderizado, de los algoritmos que comprenden la lógica del juego (y por 
consiguiente la lógica del menú). Pero vamos, repito que seguramente existan otras 
muchas formas de hacer el menú, y poder llegar a hacer cosas tan chulas como algunos 
menús, en los que das al escape, y sigue el juego su curso (y te dan cerita mientras tratas 
de cambiar las teclas... que listos). 
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10) Gestión del pintado de la pantalla: 


Ahora llega un punto ciertamente importante sobre la SDL. El como pintar en el buffer de 
pantalla. Como se ha visto antes, hemos creado nuestro genial buffer de pantalla, hemos 
cargado las texturas, pero... ¿Pero como pintamos por ejemplo las imagenes sobre el 
buffer? Es muy sencillo, solo hemos de llamar a la función SDL_BlitSurface. Esta función 
tiene 4 parámetros: 





int SDL BlitSurface(SDL Surface * imgorigen, SDL Rect * areaorigen, 
SDL Surface * imgdestino, SDL Rect * areadestino); 





Esto traducido es algo tal que nosotros tenemos una area en la imagen origen, que vamos 
a pegar en un area de la imagen destino. Por ejemplo, nosotros queremos pegar la 
imagen del fondo de la pantalla, sobre el buffer principal de la pantalla. Justo en este caso 
da la casualidad de que el area de origen es toda la imagen en sí, con lo que cuando 
queramos que el area sea toda la imagen en sí, podremos pasarle NULL como parámetro 
a la función. De forma similar ocurre con el area destino, en este caso queremos que se 
pegue sobre todo el buffer de pantalla, con lo que pasaremos NULL al parámetro 
areadestino. Así que con esto nos podemos crear una función para poner texturas en el 
buffer de pantalla: 


int PonerImagen (tNucleo * Nucleo, SDL Surface * imgsrc, 
SDL_Rect * destino, SDL Rect * origen) 
1 





// Pega en el area destino del buffer de pantalla, el area origen del 
// buffer imgsrc. 
return SDL BlitSurface(imgsrc, origen, Nucleo->BufferPantalla, destino); 














Y para poner la imagen del fondo la llamaríamos de la siguiente forma: 


PonerImagen (Nucleo, Nucleo->Texturas.imgFondo, NULL, NULL); 


Sin embargo para casos como el de pintar una nave como puede ser la del jugador, en el 
buffer de pantalla, aunque vamos a pintar toda la textura en este caso, no la vamos a 
pintar sobre toda la pantalla, eso quedaría poco propicio. Primero prepararíamos un 
SDL_Rect (SDL_Rect destino;), donde indicaremos el area de destino, y llamaremos a la 
función así: 


PonerImagen (Nucleo, Nucleo->Texturas.imgSpike, destino, NULL); 


O también podemos indicar una región dentro de la imagen, como pasará con las texturas 
de los malos, los disparos o las fuentes. En estas no querremos pintar toda la imagen, tan 
solo una región, y por ello fue que nos creamos a la hora de cargar las texturas, los 
vectores que almacenaban las regiones que había en cada textura, para que luego al 
pintarlas, usemos estos SDL_Rect almacenados en el vector, para indicar que parte 
queremos pintar. 


Pero tras hacer esto, es posible que no te salga nada en pantalla. Eso se debe a que 
usamos la técnica del doble buffer, como se explicó arriba a la hora de inicializar el SDL. 
Una vez hayamos pintado toda la escena, sin duda alguna querremos mostrarla por 
pantalla. Para ello hemos de llamar a SDL_Flip, pasandole como parámetro el buffer 
primario de pantalla: 


19 


int ActualizarPantalla (tNucleo * Nucleo) 


( 





// Actualiza el buffer de la pantalla. 
return SDL Flip(Nucleo->BufferPantalla); 














Y con esto podremos pintar imagenes en pantalla de forma bastante eficaz. Pero claro, no 
todo el campo es oregano, y aunque con solo dos funciones podemos hacer todo un 
mundo, ese mundo tiene una serie de patrones. Por ello en el juego a la hora de pintar la 
escena tendremos que pensar qué es lo que tenemos que pintar, y como tendremos que 
hacerlo (con que orden por ejemplo). Por ejemplo en el tema del menú para la pantalla de: 
+ "Menú de Nueva Partida": Pintaremos la imagen donde tenemos el menú, y luego 
comprobaremos una por una, si el cursor del ratón está dentro de algún area 
comprendida por algún "botón". Si lo está, pintaremos encima de dicha area, una 
imagen con el botón cambiado de color (para que se note que está seleccionado). 

+ "Opciones": Pintaremos la imagen de fondo que deseemos, y para este caso puse las 
instrucciones en esta sección, porque para hacer una sección de opciones es mucho 
curro. Así que el poner las instrucciones simplemente es pintar cadenas de texto, en una 
coordenada específica. 

+ "Puntuaciones": Pintamos la imagen de fondo que queramos, y vamos pintando las 
cadenas de texto, sobre este fondo, para mostrar las puntuaciones. 

+ "Menú de Continuar Partida": Es como el de "Nueva Partida", solo que tras pintar la 
imagen del menú, pintaremos encima del botón de "Nueva Partida", otro botón con el 
texto cambiado, que ponga "Continuar Partida", y cuando el ratón esté encima de los 
botones, usaremos una imagen específica como en el menú de "Nueva Partida", para 
que parezca que está seleccionado. 

+ "Poner Nombre”: Pintamos un fondo, y pintamos algún mensaje de texto, y lo que 
llevemos del nombre metido. 


Pero la parte más interesante es saber como renderizar una escena del juego. Como el 
código está ahí abajo en un link a un zip, no voy a ponerlo aquí, porque es un tanto largo. 
Más que nada voy a explicar un poco a grandes rasgos como funciona la parte del código 
que pinta una escena del juego. Primero pintamos el fondo del juego, y luego en mi caso 
he llamado a la función que pinta el resto. Se podía haber metido la sentencia de pintar el 
fondo dentro de la función Renderizado, pero bueno... tampoco pasa nada por que esté 
fuera. 


Una vez dentro de Renderizado en este juego tenemos básicamente cuatro cosas: el 
fondo, los disparos, las naves, y la interfaz del usuario. Así que tenemos primero que 
pensar en que orden lo vamos a pintar, ya que lo último que pintemos saldra por encima 
del resto. Para este caso, lo pintaremos en este orden: primero el fondo, luego todos los 
disparos que existan, luego todas las naves, y finalmente la interfaz. Como el fondo ya lo 
tenemos pintado, lo primero a hacer en la función Renderizado es ir disparo por disparo 
pintandolo sobre la pantalla. Después iremos nave por nave pintandola sobre la pantalla. 
Y finalmente pintaremos la interfaz, que en este caso es solo un marcador de puntos y 
uno de vida. 
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11) Gestión de la lógica del juego: 


Bien así que básicamente ya sabemos que es lo que tenemos que hacer en la parte del 
pintado de la escena. En el tema de la lógica lo primero que siempre vamos a hacer es 
actualizar la entrada del teclado y el ratón. Esto es fundamental, porque con eso es con lo 
que el jugador manejará su nave, por ejemplo. Así que dependiendo de en qué sección 
esté del menú, hará lo siguiente: 

+ "Menú de Nueva Partida": Si hacemos click con el botón izquierdo del ratón, entonces 
comprobaremos si el ratón está dentro del area de algún botón. En caso afirmativo 
cambiaremos el estado del juego. Si iniciamos una nueva partida, no solo se cambiará 
el estado, sino que además inicializaremos las variables que gestionen el tema de la 
partida. 

+ "Opciones y Puntuaciones”: Si damos a la tecla escape volvemos al menú principal, y 
dependiendo de si hemos empezado una partida o no, volveremo al menú de nueva 
partida o al de continuar una empezada. 

+ "Menú de Continuar Partida": Si hacemos click con el botón izquierdo del ratón, 
entonces comprobaremos si el ratón está dentro del area de algún botón. En caso 
afirmativo cambiaremos el estado del juego. 

+ "Poner Nombre": Aquí comprobaremos si el usuario ha pulsado enter, en ese caso 
comprobamos que la variable que almacena el nombre del jugador no esté vacía. Si no 
lo está, tratamos de meterla en las puntuaciones, y cambiamos el estado para ir a la 
pantalla de puntuaciones. Si pulsa el escape pasamos de meter las puntuaciones, y 
volvemos directamente al menú. Para el resto de teclas, llamamos a la función 
CapturarNombre, donde dependiendo de la tecla que hayamos pulsado, añadimos un 
caracter a la variable nombre, y así el usuario puede meter el nombre por teclado. 


La función más importante de las que hay en estos estados es la de iniciar una nueva 
partida. En esta cambiaremos el estado del juego, diremos que vamos al estado de jugar, 
y que hemos iniciado una nueva partida. También inicializaremos el nombre y la 
puntuación del jugador. Las variables para controlar los temas de la sincronización, la 
dirección hacia donde se mueven las naves y la lista de disparos, son otras variables de 
las que depende el juego de ejemplo. Finalmente tendremos que inicializar los datos de la 
nave del jugador, y la de los enemigos también. Y no hay que olvidar crear una semilla, 
para la generación de los números aleatorios, que seguramente usaremos en cualquier 
juego, para dar cierta aleatoriedad (aunque esos números tienen de aleatorio bastante 
poco). 


Así que en el estado del juego, a menos que el usuario pulse la tecla escape (con la que 
pasaremos al estado del menú de continuar partida), seguiremos la siguiente dinámica. 
Para poder controlar que la lógica se ejecute un determinado número de veces (en este 
caso es 25 por seguido, lo que sería cada 40 milisegundos), el intervalo que hemos 
recibido por los parámetros lo añadimos a una variable llamada TiempoAcumulado. 
Cuando esta tenga un valor mayor o igual que el tiempo mínimo, que en este caso es 40 
ms, entonces ejecutaremos un ciclo de la lógica del juego. De hecho la ejecutaremos 
tantas veces como nos de la división entera de TiempoAcumulado entre el tiempo mínimo 
(85 / 40 = 2 ciclos). Para ello cada vez que terminemos un ciclo, le restaremos 40 ms a 
TiempoAcumulado. 


Nucleo->Partida.TiempoAcumulado += Intervalo; 


if (Nucleo->Partida.TiempoAcumulado >= TMPMIN) 
1 





while (Nucleo->Partida.TiempoAcumulado >= TMPMIN) 
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InterpretarEntrada (Nucleo); 
EjecutarlA (Nucleo); 








Nucleo->Partida.TiempoAcumulado -= TMPMIN; 


La última sentencia, donde TiempoAcumulado pasa a valer cero, podríamos saltarnosla, y 
de hecho así el control sería más exacto, porque los ms que hayan sobrado de la resta de 
los ciclos, podrían ir acumulandose y podría ser que perdieramos algún ciclo. Pero para 
este juego perder algún ciclo de vez en cuando tampoco va a hacer que se ejecute mucho 
más lento, tan solo más o menos 40 ms más lento cada cierto tiempo. 


El grueso de la lógica, lo forman dos funciones InterpretarEntrada y EjecutarlA. En la 
primera, veremos el estado de la entrada, y en base a ello, decidiremos que es lo que nos 
está pidiendo el jugador que hagamos. Y la segunda ejecuta el comportamiento de todas 
las entidades del juego. Esto es un tema curioso, porque en terminos "absolutos", no solo 
los enemigos tienen una lA, desde el punto de vista de lo que representa la lA en la 
programación de juegos. La lA, más que un comportamiento inteligente, es un patrón 
definido de comportamiento, porque rara es la lA de juego que tiene una memoria, ya que 
eso consumiría muchos recursos. Por ello un disparo de un arma tiene una lA, como por 
ejemplo el cohete que lanzas en el Quake. Por ello cada vez que ejecutamos la función 
para realizar un ciclo de la lógica de todas las lA, esto básicamente significa, realizar un 
ciclo en el comportamiento de todas las entidades del juego. 


InterpretarEntrada básicamente lo que hace es comprobar el estado de las teclas flecha 
izquierda, flecha derecha, y espacio. Si pulsamos la flecha izquierda, la nave tendrá que 
moverse a la izquierda (decrementar el valor en su eje x), y si pulsamos la flecha derecha, 
la nave se desplazará hacia la derecha (incrementando el valor en su eje x). Pero para 
este juego hemos puesto algunas restricciones, de cual es el valor máximo en el eje x, 
sobretodo para que no se salga de la pantalla la nave, que sería todo un desastre. Así 
que si además pulsamos la tecla espacio, la nave generará un disparo, llamando a la 
función CrearDisparo, que crea un nuevo nodo de tipo tDisparo, en la lista doblemente 
enlazada que se usa en el juego. 


EjecutarlA es una función ligeramente más elaborada. En ella lo primero que tenemos que 
hacer es ejecutar un ciclo de comportamiento de todas las entidades de tipo disparo. Para 
ello iremos nodo por nodo de la lista de disparos, comprobando primero si han colisionado 
con algo, en ese caso inflingimos el daño que produce el disparo, y destruimos el disparo. 
Suponiendo que no colisione con nada, hacemos avanzar el disparo hacia la dirección 
contraria del bando que lo ha lanzado. Y si se sale de los limites mínimo y máximo que le 
indicamos para el eje y, destruimos el disparo. 


Tras esto comprobamos que el jugador no esté muerto, en caso de estarlo se finaliza el 
juego. Pero si sigue vivo miramos a ver si sigue viva alguna nave. En el caso de que 
estén todas muertas, pasamos al siguiente nivel, llamando a SiguienteNivel, que cambiará 
los valores de algunas variables, y volverá a inicializar el contenido de la mayoría. 


Y ahora vamos a comprobar nave por nave enemiga, siempre que esta esté viva lo 
siguiente. Primero avanzaremos un paso en la dirección actual, y decidiremos de forma 
aleatoria si dispara o no. En este caso en concreto la expresión base para disparar o no, 
viene dad por lo siguiente: (rand() % 100) devuelve un número entre O y 99, y en una 
variable de la nave llamada frec, tenemos el porcentaje máximo para que la nave dispare, 
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esto quiere decir, que si el número devuelto es menor o igual que frec, entonces la nave 
disparará. 


Pero esto no termina ahí. Tenemos que volver a recorrer el vector de naves enemigas, 
comprobando de entre las vivas, si alguna ha sobrepasado los limites mínimo (si se dirige 
a la izquierda) o máximo (si se dirige a la derecha) del eje x. Si existe alguna nave que 
cumpla eso, tendremos que hacer que todas las naves vivas avancen un paso hacia 
abajo. Y comprobar de paso si alguna nave ha llegado hasta el fondo de la pantalla, con 
lo que significaría el fin de la partida. 


Hay un detalle que todavía no he explicado, y es que una de las variables para controlar 
los ciclos de ejecución CuentaAct y CuentaMax, son empleadas para determinar cada 
cuantos ciclos las naves enemigas ejecutan su lA. CuentaMax indica cuando ocurre eso, 
empieza siendo cada 25 ciclos de lógica, y si sobrevive el jugador 25 "fases", este se ve 
reducido a 1, con lo que en cada ciclo se ejecutaría la lA. CuentaAct es el contador que 
lleva el número de ciclos que ha pasado desde la última vez que se ejecutó la lA, cuando 
vale igual o más que CuentaMax, se ejecuta la Al. Y tras terminar de ejecutar la lA, 
CuentaAct pasa a valer 0, para empezar de nuevo con la cuenta de ciclos de lógica. 
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12) El tema de pintar texto en la pantalla: 


Ya como nota final, una función bastante útil, sobre todo para el menú es la función 
PintarCadena. Esta función pinta en el buffer principal una serie de imagenes con 
transparencia, en las que fijate tú, casualmente hay una letra del abecedario. Pero 
primero tenemos que tener en una imagen todos los caracteres que vamos a usar en el 
juego, medirlos, y constuir automáticamente con una lista de los anchos de cada caracter, 
un vector de areas para saber donde esta cada imagen. 


Entonces en la función PintarCadena, le pasamos una coordenada (x, y), y una cadena de 
caracteres. Vamos uno por uno, analizando que caracter es y calculando en que posición 
del vector de areas, está el area que corresponde con la imagen del caracter actual. Una 
vez tenemos esa posición, pintamos esa región con el caracter dibujado, en una región 
destino del buffer de pantalla, formado dicho SDL_Rect, por las (x, y) que nos pasaron en 
los parámetros, y el ancho y alto de la región, que hemos obtenido del vector de areas. 
Finalmente tras pintarla, añadimos a la x el ancho actual del caracter que acabamos de 
pintar, para que no se pinten todos encima de la misma posición. 


Y así es como se solía hacer para dibujar texto en un juego, pero por suerte para todos 
aquellos que no quieran morirse de asco, midiendo letra por letra como me pasó a mi... 
SDL tiene otra extensión que se llama SDL_ttf, que sirve para manejar las fuentes true- 
type, que vienen con el sistema operativo, o con tu propio juego. Con lo que nos 
ahorraremos mucho trabajo, y tendremos a nuestra disposición muchísimas prestaciones. 
Pero siempre queda el método clásico, en caso de no tener nada más que el propio 
ingenio. 
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